Beatsのアウトプットを加工する
はじめに
藤本です。
みなさん、Beats使っていますか?
過去のエントリで全公式+一つのコマーシャルBeatsを紹介してきました。
- Topbeat + boot2dockerでMacBookのシステムモニタリング
- Filebeat + boot2dockerでMacBookのログモニタリング
- Packetbeatでパケットモニタリング
- WinlogbeatでWindowsログモニタリング
- RedisbeatでAmazon ElastiCache(Redis)をモニタリングする
概要
Beatsは軽量なデータ収集ツールです。Golangで実装されていて、軽量なフットプリント、クロスプラットフォームで動作するため、各種クライアントで動作させるには嬉しいですね。JRuby(JVM上)で動作するLogstashと比較しても導入のハードルは低いでしょう。
ただし、Beatsを導入すればLogstashはいらない子かと言うと、そんなことはありません。Beatsは軽量さを重視していることから変換・加工・出力処理を担うlibbeatに実装されている機能は限られたものとなっています。以下のような制限があります。
- データの変換・加工機能が少ない Logstashのように豊富なフィルタープラグインを持っていません。 例えば、Filebeatでログメッセージを収集する場合、messageフィールドにログメッセージをそのまま値として割り当てます。以前、様々なファイルをデータソースにElasticsearchへデータ投入するで紹介したようなgrokフィルター、mutateフィルターのような変換・加工処理がありません。
-
出力先が少ない 現在、サポートされている出力先は以下となっています。Logstash、Fluentdを使っていた方は不満を感じるでしょう。
- Elasticsearch
- Logstash
- File
- Console
- Redis (Deprecated)
そこで今回はFilebeatとElasticsearchの間に多種多様な変換・加工機能を持つLogstash / Fluentdを中継して、パースしたApacheのアクセスログをElasticsearchにインデックスし、Kibanaで可視化するユースケースを例に実装方法をご紹介します。
環境
- WEBサーバ
- IPアドレス : 10.255.0.102
- OS : Centos 6.7
- Apache : 2.2.
- Filebeat : 1.1.0
-
転送中継サーバ
- IPアドレス : 10.255.0.104
- OS : Centos 6.7
- Logstash : 2.2.0
-
Fluentd : 2.3.0
-
可視化サーバ
- IPアドレス : 10.255.0.100
- OS : Centos 6.7
- Elasticsearch : 2.2.0
- Kibana : 4.4.0
Logstashでやってみた
Beatsは概要でも説明した通り、標準でLogstashへの出力をサポートしています。またLogstashはバージョン2系から標準でBeatsのinputプラグインを持っています。
インストール
Filebeat、Logstash、Elasticsearch、KibanaのインストールはElasticプロダクトインストールまとめ(RedHat系)をご参照ください。
Filebeat設定
Beatsの設定ファイルはYAML形式です。最低限の設定ですが、対象のログファイルにaccess_logのパスを指定し、出力先はLogstashサーバを指定します。
# cat /etc/filebeat/filebeat.yml filebeat: prospectors: - paths: - /var/log/httpd/access_log input_type: log output: logstash: hosts: ["10.255.0.104:5044"]
Logstash設定
inputにbeatsを指定します。port番号の指定だけ必須項目です。 filterはgrokでaccess_logのメッセージフォーマットでパースし、dateでタイムスタンプのフォーマットを変換します。 outputはelasticsearcを指定します。
# cat /etc/logstash/conf.d/logstash.conf input { beats { port => 5044 } } filter { grok { match => { "message" => '%{IPORHOST:clientip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "%{WORD:verb} %{DATA:request} HTTP/%{NUMBER:httpversion}" %{NUMBER:response:int} (?:-|%{NUMBER:bytes:int}) %{QS:referrer} %{QS:agent}' } } date { match => [ "timestamp", "dd/MMM/YYYY:HH:mm:ss Z" ] } } output { elasticsearch { hosts => ["10.255.0.100:9200"] index => "accesslog-%{+YYYYMMdd}" } }
動作確認
ログ生成
適当にWEBサーバにHTTP Requestを送信して、access_logに追記します。
Elasticsearchのインデックス
Elasticsearchでインデックスが作成されていることを確認します。
# curl 10.255.0.100:9200/_cat/indices yellow open .kibana 1 1 1 0 3.1kb 3.1kb yellow open accesslog-20160209 5 1 30 0 147.1kb 147.1kb
可視化
Kibanaで可視化します。
HTTP Responseのステータスコードで分類したシンプルな円グラフです。ちなみにKibana 4.4.0の新機能で色を指定画面右側にあるように各値に対して色を割り当てることができました。これでゴレンジャーの好きなキャラクターのグラフを作る時にアカレンジャーなのにグラフ上の色は緑とかならなくてすみます!
Fluentdでやってみた
Elasticsearch勉強会#14で@repeatedlyさんが紹介していました。Fluentdのプラグインとして、Beatsのインプットプラグインを開発されています。BeatsのGAがリリースされてすぐにリリースされているのはスゴイ!Elastic社独自のlumberjackというプロトコルをFluentdで受け取ることができます。
Filebeat設定
変更の必要はありません。
Fluentd設定
プラグインインストール
beatsの入力プラグイン、elasticsearchの出力プラグインは標準ではないプラグインですので、gemからインストールします。
# /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-beats fluent-plugin-elasticsearch (略)
設定
sourceはBeatsからデータを受け取るため、typeにbeatsを指定します。またメッセージフォーマットはhttpdログフォーマットのcombinedなので、formatにapache2を指定します。
出力先はElasticsearchを指定します。
# cat /etc/td-agent/td-agent.conf @type beats tag beats format apache2 type elasticsearch host 10.255.0.100 port 9200 logstash_format true logstash_prefix fluentd
動作確認
ログ生成
適当にWEBサーバにHTTP Requestを送信して、access_logに追記します。
Elasticsearchのインデックス
Elasticsearchでインデックスが作成されていることを確認します。
# curl localhost:9200/_cat/indices yellow open .kibana 1 1 3 0 13kb 13kb yellow open fluentd-2016.02.09 5 1 52 0 84.2kb 84.2kb yellow open accesslog-20160209 5 1 31 0 162.6kb 162.6kb
可視化
Kibanaで可視化します。
まとめ
いかがでしたでしょうか? Beats+Elasticsearch+Kibanaはシステムモニタリングに非常に強力な組み合わせです。更に今回紹介したようなLogstash、Fluentdのようにデータを変換・加工することで更にユーザーに適した形でモニタリングすることが可能です。